Date: Mon, 30 May 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #104 To: tcp-group-digest TCP-Group Digest Mon, 30 May 94 Volume 94 : Issue 104 Today's Topics: Gracillis Mail failure More RSPF Help needed..... TCP-Group Digest V94 #103 unsub Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Sat, 28 May 94 10:41:37 CDT From: route66@ddl.chi.il.us (System Administrator) Subject: Gracillis To: tcp-group@ucsd.edu I have been looking into buying Gracillis for 9600 baud packet. Has anyone ever tried it..and if so, how is it on TCP/IP? Also, I'd rather not spend $1,000 for Gracillis new..by chance does anyone out there have a used one setup they wanna get rid of? Thanks, Greg Kaiser - N9TOL ------------------------------ Date: 29 May 1994 09:04:09 EST From: "POSTMASTER" Subject: Mail failure To: TCP-Group@UCSD.EDU Date: Sat, 28 May 94 04:56:05 CST From: Jack Snodgrass Subject: More RSPF Help needed..... To: tcp-group mailling list We've been tearing out my hair trying to figure out how to link 2 RSPF routers that use an IP Router to communicate. It seems like RSPF should work and NOT require that every station in the network Run RSPF, but we just can't figure out how to make it work. We've got: -------- -------- -------- kf5mg <---440---> wb5tey <---144---> k5rw -------- -------- -------- kf5mg and k5rw are running RSPF. When either one sends out it's RSPF broadcast, the other station can't hear it because they're on separate networks. Is there an easy way to fix this? We've set up and AXIP link between the two RSPF routers and set up the routes between k5rw and kf5mg to use wb5tey. Now they can hear each others RSPF broadcast, but the RSPF added routes are screwed up. All of k5rw's RSPF added routes on kf5mg show that they route through k5rw on 440 instead of wb5tey. All of kf5mg's RSPF added routes on k5rw show that they route through kf5mg on 144 instead of wb5tey. I'm guessing that the reason the routes are screwed up is that RSPF assumes that since it can 'hear' the station direct ( because of the axip link ) the RSPF added routes assume that they go direct to the remote system and don't take into account any pre-existing routes set up between the two RSPF routers. Next, we set up an ENCAP link in hopes that if the AXIP link was run over the ENCAP link the RSPF added links would use the ENCAP link routes. That didn't work either. The AXIP stuff goes over the ENCAP route, but the RSPF added routes still ignore the IP router that's in between the two RSPF routers. Someone is probably going to suggest that wb5tey ( in our example ) run RSPF. Yes... that will work, but I want/need to figure out this problem. Once we get this working, we'll add RSPF to both of our Internet Gateways. There's no way to get the network routers between the two gateways to run RSPF. Anyway.... either there is something basic that I'm missing or RSPF is really un-usable in a standard network and I can't see how one can really be using it. Any info/help/suggestions ( preferably working ) would be appreciated. Thanks. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386 Dialup - kf5mg@tcet.unt.edu - work (looking for) ============================================================================== = === Buffalo's new area code.... 044.... "Deal with it" == = ============================================================================== = ------------------------------ Date: Sat, 28 May 1994 16:28:01 -0400 From: goldstein@carafe.tay2.dec.com Subject: More RSPF Help needed..... To: tcp-group@ucsd.edu Jack, > We've got: > > -------- -------- -------- > kf5mg <---440---> wb5tey <---144---> k5rw > -------- -------- -------- > > kf5mg and k5rw are running RSPF. When either one sends out it's RSPF >broadcast, the other station can't hear it because they're on separate >networks. Is there an easy way to fix this? Not an easy way... This would have been solved fairly easily had RSPF2.2 been implemented. RSPF2.2 is a spec that makes clear that "normal" IP rules of "subnets" do NOT apply, and therefore you can create adjacencies using any kind of lower-layer (subnetwork in the OSIRM sense) connection and RSPF will use them if appropriate. But the code in NOS does not override IP's routing function, and treats RSPF node groups as IP subnets, which they ain't. I don't know what hackery has been done recently to allow faking things, but it's all half-way. Note that RSPF was designed to run on routers, but not be needed on end stations. Your example is of course the opposite, and tries to use intellgent end systems to get past a lack of intelligent routers. Perfectly sensible but since I don't personally _use_ any of the RSPF variants currently implemented, I can't tell you what works. If somebody would take the 2.2 spec and really implement it... Naaah, we're hams. Why do it right when a quick and dirty early hack is available? Why should routing be different from the "202" modems? :-( (sig)> Buffalo's new area code.... 044.... "Deal with it" I must be missing something... fred k1io ------------------------------ Date: Sat, 28 May 94 11:21:03 CST From: fchavarr@udgserv.cencar.udg.mx (Fco. J. Chavarria -POLITEC) To: tcp-group@UCSD.EDU unsub fchavarr@udgserv.cencar.udg.mx ------------------------------ End of TCP-Group Digest V94 #103 ****************************** ------------------------------------------------------------------------------ ------------------------------ Date: Sun, 29 May 94 05:48:00 -0000 From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow) Subject: More RSPF Help needed..... To: tcp-group@UCSD.EDU Cc: kf5mg@kf5mg.ampr.org JS> We've been tearing out my hair trying to figure out JS> how to link 2 RSPF JS> routers that use an IP Router to communicate. It seems like RSPF should JS> work and NOT require that every station in the network Run RSPF, but we JS> just can't figure out how to make it work. I understand your problem exactly. There really are no easy ways to do what your want, but it should be possible. However, it is an involved thing and I don't want to sit here typing away nonsense before I think it through. A lot of these kinds of problems are a result of features in the formal RSPF spec remaining unimplemented. RSPF was intended to function as an interior routing protocol within the autonomous system which is Amprnet. The expectation was that all routers would be running the routing protocol. This is not an unreasonable expectation, and it applies pretty much equally to any other routing protocol besides RSPF. End nodes which have no routing responsibility are not usually expected to run RSPF, but that is a very different thing. -- Mike ------------------------------ Date: Mon, 30 May 1994 09:05:19 CET From: "Jack Stiekema" Subject: TCP-Group Digest V94 #103 To: Advanced Amateur Radio Networking Group >> We've been tearing out my hair trying to figure out how to link 2 RSPF >>routers that use an IP Router to communicate. It seems like RSPF should Maybe a silly question, but what is RSPF? Kind regards, Jack Stiekema Product Manager Connectivity +----------------------------------------------------+ | Victron bv POB 31 9700 AA Groningen Holland | | Phone: +31 50 446222 Fax: +31 50 424107 | | Email: jack@victron.nl Internet: 193.78.6.6 | | Home: +31 5980 80498 pe0mot@pe0mot.ampr.org | +----------------------------------------------------+ ------------------------------ Date: Mon, 30 May 1994 10:43:38 MET From: betaille@lurvax.lure.ups.circe.fr Subject: unsub To: tcp-group@ucsd.edu unsub betaille@lure.ups.circe.fr tcp-group ------------------------------ End of TCP-Group Digest V94 #104 ******************************